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DETAILED ACTION 

1 . This Office Action is in regards to the most recent papers filed on 5/25/2007. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

3. Claims 1-4, 6-14, and 16-17 are rejected under 35 U.S.C. 102(e) as being 
anticipated by US Patent Application Publication number US 2003/0236912 A1 to 
Klemets et al. v hereafter referred to as "Klemets." 

With regards to claim 1, Klemets discloses a method for streaming a media file 
over a distributed information system to a client computer running a browser application, 
the method comprising the steps of: receiving a request for a particular media file from a 
client computer (Klemets: Paragraph [0016]); providing a metafile, whereby said 
metafile contains information about the identification (Klemets: Paragraph [0038]. The 
"Title" field is information about the identification.), location (Klemets: Paragraphs [0012] 
and [0041]. The metadata includes a stream attribute identifying a media stream, where 
a media stream identifier has a one to one relationship with a URL, which means that 
the stream attribute constitutes location information.), and format (Klemets: Paragraph 
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[0035]. The metadata can be the encoded bit rate and the language, both of which 
constitute format.) of the media file, returning said metafile back to said client computer 
(Klemets: Paragraph [0039]), characterized in that the step of receiving a request for a 
particular media file from a client computer further comprises the steps of: intercepting a 
download request for the actual media file (Klemets: Figure 1. The media server 
intercepts the request from the client, and serves the media file from the file system to 
the client.) and reinterpreting said download request in a request for receiving a 
corresponding metafile (Klemets: Paragraph [0033]. As a result of the server receiving 
a request for a media file, the server requests metadata items from the file system 
and/or encoder. As the server is requesting items in addition to the one that the client 
requested, the request has been "reinterpreted" into a request for the media file and the 
metadata.). 

With regards to claim 2, Klemets discloses that the step of reinterpreting said 
download request includes the step of deriving information about said corresponding 
metafile from a portion of the URL (Klemets: Paragraph [0031]. The URL determines 
the media file being requested, meaning that it is utilized, at least in part, to obtain the 
metadata.). 

With regards to claim 3, Klemets discloses that the portion of the URL is the file 
extension of the requested media file (Klemets: Paragraph [0056], The system of 
Klemets assigns attributes based in part if the format is ASF, which is the file extension 
as per paragraph [0031]). 
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With regards to claim 4, Klemets discloses that the step of providing a metafile 
comprises the steps of: dynamically generating a metafile (Klemets: Paragraph [0038]), 
and statically querying a metafile (Klemets: Paragraph [0038]. As the metadata items 
may be obtained from a separate file, the file is "queried" for the information.). 

With regards to claim 6, Klemets discloses that the step pf providing a metafile 
further includes the step of retrieving information about the configuration of at least one 
item chosen from the group comprising: version of the streaming product, type of the 
streaming product, location of the media file, load of the servers, load of the network, 
location of the client, quality of service (Klemets: Paragraphs [0049], [0074], [0075]. 
The items in the list are broad, as information about the version of the streaming 
product could constitute the file name, which is included in Klemets. The type of the 
streaming product can constitute any number of elements, some examples being found 
in the cited paragraphs. Also, to meet the claim language, any configuration information 
meets the language, as the group comprises version, type, location, load of the 
servers, load of the networks, location of the client, and quality of service. The open- 
ended language does not exclude the configuration information from being an element 
not on the list.). 

With regards to claim 7, Klemets discloses that the step of providing a metafile 
further includes reading information about the client's preferred streaming format and 
forming a metafile in accordance with the client's preference (Klemets: Paragraph 
[0044]. The client is able to select different parameters involved with the streaming 
media file, including whether the file will be played as just audio, or as audio and video. 
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As the metafile is able to be generated based on the client's request, these factors 
would be at least read and used somehow to generate the metafile.). 

With regards to claims 8-14 and 16-17, the claimed subject matter is substantially 
similar to the subject matter found in claims 1-4 and 6-7, and is rejected for substantially 
similar reasons. 

With regard to claim 18, the instant claim is substantially similar to subject matter 
presented in claims 1-4, 6-13, and 15-17, with the exception that a MIME-type is 
provided at the metadata server and returned with the metafile to the client computer. 
However, Klemets discloses that a MIME type is included in the header, which is 
returned to the client (Klements: Paragraph [0049]). 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this, title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. Claims 5 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Klemets over knowledge possessed by a person of ordinary skill in the art. 

With regards to claim 5, Klemets discloses the invention as substantially claimed 
(see above for claim 1 rejected under Klemets) except checking predefined filter criteria 
determining of whether or not a metafile is to be returned instead of the requested 
media file. 
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A person of ordinary skill in the art would have known how to perform this 
functionality. If the metafile is returned, the media file is to be streamed. If the media 
file is returned, then the media file is being downloaded rather than being streamed. 
The predefined filter can simply be the determination of what kind of request is being 
presented from the client. 

It would have been obvious at the time of the invention to give the client a choice 
to download the media file or stream the media file, as represented by providing the 
metafile, in the system of Klemets. 

The suggestion/motivation for doing so would have been that different system 
configurations and network configurations has a preference for downloading or 
streaming. In cases where memory is limited, streaming may be preferred. In cases 
where bandwidth is limited, downloading may be preferred, as the connection speed 
may not be able to support the streamed media, while a download would allow the user 
to access the media at an acceptable quality at a later time. Even if bandwidth is not 
limited, downloading may still be preferable as the client would have its own copy of the 
media file, allowing the client to access the file as often as desired without requiring a 
connection. Allowing a choice to be made based on the request, and providing a filter 
that determines whether the request should be responded to with metadata to allow 
streaming or the media file itself allows the client to optimize access to the file based on 
network conditions, the client's configuration, and the user's preferences. 

With regards to claim 15, the claim is substantially similar to claim 5, and is 
rejected for substantially similar reasons. 1 
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Response To Arguments 
Rejection of Claims under 35 U.S.C. 102(e) 

With regard to the rejection of claims 1 , 8, and 1 1 , applicant argues that Klemets 
does not disclose "receiving a request for a particular media file from a client computer." 
Applicant also argues that Kemets also does not disclose that a metafile or metadata is 
returned. 

With regards to the arguments that Klemets does not disclose "receiving a 
request for a particular media file from a client computer," examiner notes that Kemets 
relies on Real Time Streaming Protocol, which is described in RFC 2326 by 
Schulzrinne, et. Al. in April of 1998, hereafter referred to as "RFC2326." RFC2326 
discloses that real time streaming protocol, at the minimum, involves the client sending 
a describe request, the server sending a response, then the client sending a setup 
followed by a play request to begin playing the file, with the session ending with a 
teardown to terminate the session (RFC2326: Section 10). 

Real Time Streaming Protocol requires some method for initializing the media, 
and sets forth three methods for doing so (RFC2326: Section 10.2), with DESCRIBE 
being one of the methods to initialize the media. The DESCRIBE response includes 
information that is required to initialize the streaming media presentation, which may 
include the streaming media header (Klemets: Paragraph [0031]). Then the SETUP 
method is used to establish the connection to the server (Klemets: Paragraph [0032]), 
and finally, the client selects to play the streams (Klemets: Paragraph [0045]). 
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It is noted that a media file, in general, has two portions, a header portion and the 
actual video and/or audio portion. The header portion includes information on the video 
and/or audio portion that is required in order the present the media file. The teachings 
of Klemets requires that the DESCRIBE method be used in order to obtain the header 
portion, which is part of the media file as a whole. It is also noted that the RTSP 
DESCRIBE method requires identification of a particular media file (RFC2326: Section 
10.2), which is typically identified by a specific URL. As such, the header may be 
considered to be part of the media file as a whole, where the RTSP DESCRIBE method 
begins download of the media file by downloading the header, then allowing the client to 
issue commands such as PLAY, PAUSE, RECORD, etc. A person of ordinary skill in 
the art would not interpret the PLAY method as requesting the specific media file (See, 
for example, Patent 6,640,244 B1 to Bowman-Amuah column 72, lines 1-8), which 
means that it would be recognized that the DESCRIBE method, as it is used to initialize 
the process for beginning a streaming media session, and requires identification of a 
specific presentation or media object that is identified by the request URL (RFC2326: 
Section 10.2, paragraph 1). 

It is further noted that claim 1 does not specifically state what constitutes a 
request for a particular media file, as the request for a particular media file is not 
necessarily a request to download a particular media file, but may instead be a request 
that pertains to a particular media file, or, more specifically, a download request for 
information that pertains to a media file. 
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With regards to the argument that Kemets also does not disclose that a metafile 
or metadata is returned, Applicant seems to acknowledge that the SDP message, which 
is returned in response to the RTSP DESCRIBE method, may arguably contain 
metadata, and does not provide specific arguments of how it does not contain 
metadata, this argument does not warrant a response at this time. 

Applicant has attempted to challenge the Examiner's assertion of what is well 
known in the art with respect to "checking predefined filter criteria determining of 
whether or not a metafile is to be returned instead of the requested media file" in the 
paragraph joining pages 14-15 of Applicant's arguments; however, applicant has not 
provided adequate information or argument so that on its face it creates reasonable 
doubt regarding the assertion of what is well known in the art. It is noted that a 
"predefined filter criteria" could include examining what kind of request is presented, and 
simply responding to the request accordingly (i.e. a request to stream a video would 
result in the metadata being returned to allow the stream to be initialized, meanwhile a 
request to simply download the file would result in the file being downloaded. Both of 
these examples are automatically responded to by checking predetermined criteria to 
determine what kind of request is being made, then determining whether to return 
metadata or the media file.). Applicant has made no showing that a person of ordinary 
skill in the art would not be able to have a server differentiate between a request that 
would require metadata (i.e. streaming media) and a request that would require the file 
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to be returned (i.e. a request to download the entire file). Therefore, the rejections of 
claims 5 and 15 are maintained. 



Conclusion 

6. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott Christensen whose telephone number is (571) 
270-1 144. The examiner can normally be reached on Monday through Thursday 
6:30AM -4:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Vaughn William can be reached on (571) 272-3922. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 






